1. Technical Field
The present disclosure relates to methods, systems, and programming for reducing network latency.
2. Discussion of Technical Background
Network latency is the time it takes for a data packet to transmit from point A to point B in a network. It can be measured with either one-way or round-trip time (RTT). If A and B are connected via LAN (Local Area Network), normally the RTT may range from less than 1 ms to 5 ms. On the other hand, if A and B are connected via long haul (e.g. cross-the-ocean or trans-continent) WAN (Wide Area Network), the RTT may range from 100 ms to 200 ms or even more.
HTTP (Hypertext Transfer Protocol) serving is based on TCP (Transmission Control Protocol), which requires a 3-way handshake (1 RTT) for connection setup before real application data can be transmitted from a server to a client, or the other way around If the client and the server are connected via long haul WAN, a high latency may severely impact user experience. To eliminate this 1 RTT over WAN, some content providers deploy static HTTP contents in partner locations that are close to the users. These locations may be called PODs or relays. For dynamic HTTP content, a special HTTP proxy is deployed in the relays to maintain persistent TCP connection to origin server via WAN and perform URL (uniform resource locator) based routing.
HTTPS (Hypertext Transfer Protocol Secure) serving is based on SSL (Secure Sockets Layer) or TLS (Transport Layer Security) protocol, which requires a 4-way full handshake or a 3-way abbreviated handshake. The corresponding network latency is 3 RTT for full handshake or 2 RTT for abbreviated handshake, before real application data can be transmitted. SSL is the predecessor of TLS and it is similar to TLS in the context of this disclosure, we use TLS and SSL interchangeably hereafter. The latency may be multiplied when loading a complex secure web page, where many SSL connection setups are required. Besides, the server certificate message in SSL full handshake may be as large as 4K bytes, about 3 packets by itself. Fragmentation and possible packet loss and retransmission over WAN may add more network latency. This is also true and applicable to other protocols and applications directly or indirectly based on TCP+SSL.
There are some research and industry efforts for improving SSL network latency. Google False Start is a method of reducing the TCP+SSL full handshake to 2 round trips. However, Google False Start suffers security concerns and lack of compatibility from both the server and client side. Support of Google False Start has been dropped since Chrome version 20. Google Snap Start is another method of reducing the TCP+SSL full handshake to 1 round trip for ciphers not requiring Server Key Exchange message, e.g., PFS ciphers. However, Google Snap Start is a rewrite of the SSL protocol and suffers security concerns and lack of compatibility from both the server and client side. Support of Google Snap Start has been dropped. TLS cached into extension, an IETF (Internet Engineering Task Force) draft, is a method of helping network latency by caching certificate chain of known server at the client side. However, it does not reduce network round trips in a full TCP+SSL handshake. And it does not help abbreviated SSL handshake at all.
Therefore, there is a need to provide a solution for reducing the network latency without compromising connection security.